3.1 Field of the Invention
The present invention provides systems, methods, and software for providing and managing rights to use networks and network services using digital bearer instruments that express at least one right related to providing and/or managing a network or network service. The invention has applications in the fields of computer science, networking, and electronic business methods.
3.2 The Related Art
3.2.1 Titles and Title Validation
A title is a digital bearer instrument that expresses at least one right. Title materials include titles, portions of titles, for example, such as a specific right definition, a reference to a specific title or right, and independently validatable portions of titles. A stub is one example of an independently validatable portion of a title. Title materials may also include specific instances of digital bearer instruments that may not include a specific right. Title materials are presented to title-enabled processes, computers, and devices, which use the presented title materials to operate on and/or facilitate redemption of rights expressed by a title. Titles employed by specific embodiments of the present invention are related to the title technologies provided by Navio Systems, Inc., of Cupertino Calif.
As described in U.S. Patent Publication US 2006-0036548 A1, the entire disclosure of which is incorporated herein by reference for all purposes, titles can be validated by using a title resolver and/or a state server, both of which are components of a title management system. FIG. 1 is a flow chart depicting an example of such a title validation process. The title is submitted by a client to a title resolver service for authentication (1110). The title resolver service examines the title's digital signature (1120). If the digital signature is incorrect, the title resolver service rejects the title and the title validation process terminates with an “invalid title” result. If the digital signature is correct (1130), the title resolver service forwards the title to the state server process for further validation (1140) of the state value in the title's stub. The state server process uses the state value or other indicia that are part of the title (1150), computes a value from these item(s), and compares it against a value stored in a database (1160). If the two values match (1170), the title is validated by the state server (1180). A “title valid” response is returned to the title resolver service (1190), which in turn returns a “title valid” response the client (1200). If the state server cannot validate the title, it returns a “title invalid” response and the validation process terminates. The above example is one method of validating titles; additional methods of validating title materials include digital signatures, comparison of transaction indicia to transaction databases, and other methods well known to those skilled in the art.
According to specific embodiments described in U.S. Patent Publication US 2006-0036548 A1 referenced above, when a title is used (for example, during a redeem action), the title is presented to state server for authentication by a resolver. The state server performs the authentication process and verifies the security indicia contained within the title to that of the current state maintained in the state collection. The security indicium for a title is contained in the titles authenticator stub.
The state server may also perform endorsement and authentication as supported by the title transaction ecosystem. A variety of techniques and algorithms can be supported by the title technology, and the technique and algorithm employed on a particular title can be subsequently conveyed to the state server for authentication. In one class of embodiments, a chained hash mechanism is used for title authentication. According to a particular embodiment, the chained hash may be generated by repeatedly hashing an initial value v which may include title information combined with a random number or other appropriate data using a cryptographically strong hash function H such as MD5 or SHA-1. The first iteration of the chained hash algorithm gives h0=H(v). The second iteration gives h1=H(h0). The nth iteration gives hn=H(hn−1) where n represents the desired length of the hash chain. This hash chain of length n may represent any value within the system from the maximum number of redemptions allowed by a title to the maximum number of users connected to a system, or any other value required by the system. In another embodiment, v may be composed of a random value and a hash of the title to later be used for title integrity verification.
In another embodiment, the state server component may generate hn and securely store n and the value v that was used as the initial hash value for h0. The value hn may then be set in the authenticator stub for the title along with the name of the hash algorithm used to create hn. In one instance, the client may then later present the title upon redemption where the state server may extract the value hn from the authenticator stub along with the hash algorithm name specified by that stub. The state server may then look up its stored values v and n and compute hi=Hi(hi−1) where h0=H0(v) and i={1, 2, 3, . . . , n}. The value hn would be checked for equality with hi and if equal, the title would be authenticated. The server may then store n−1 in place of n, generate a new authenticator stub containing hn−1 and the name of the algorithm used, and return that stub back to the client where the title may be authenticated again using the above process as long as n>0.
In yet another embodiment, the state server generates the hash as defined above and set the values hn, and ye along with the name of the hash algorithm used in the authenticator stub, where ye is the encrypted value v. The state server would only need to store n in this embodiment. Upon redemption, the client would present the title with the authenticator stub containing ye, hn, and the name of the hash algorithm to use. The state server component may then decrypt ye to get vd and compute hi=Hi(hi−1) where h0=H0(vd) and i={1, 2, 3, . . . , n}. The state server component would then verify hi=hn and if true, the title would be authenticated. The server may then store n−1 in place of n, generate a new authenticator stub containing hn−1, ye, and the name of the hash algorithm used, and return that stub back to the client where the title may be authenticated again using the above process as long as n>0.
In yet another embodiment, the client is responsible for generating the hash chain. In one instance, the client generates the value v using the techniques described above or another appropriate method. The client then computes the hash chain hi=Hi(hi−1) where h0=H0(v) and i={1, 2, 3, . . . , n}. The resulting hash chain={h0, h1, h2, . . . , hn}. The client sends its credentials, h0, and the name of the hash algorithm used, to the state server component. The state server component verifies the client's credentials and stores h0 in its secure data store. Upon title redemption, the client sends the title with h1 and the name of the hash algorithm embedded in the authenticator stub to the state server component for verification. The state server component retrieves h0 from its secure data store and hashes h0 using the algorithm indicated to produce h1*. The title is authenticated if and only if h1=h1*. The state server component then replaces h0 with h1 in its secure data store. The client can no longer use h1. Note that in this embodiment the client will always supply hi and the state server component will always store hi−1. The ith redemption consists of the value hi supplied by the client which the state server component can verify using hi−1. Each such redemption requires no calculations from the client and only a single hash operation by the state server component.
In another embodiment, when a chain of hashes expires, such as n=0, the state server can automatically perform a re-endorsement of the title and create a new chain. The re-endorsement can occur selectively and as permitted on the particular title.
In another embodiment, a random value technique is applied to authenticate a title. A random value is generated by the state server and placed in the authenticator stub. The state server also maintains a record of the random value in its state collection. The random value would be changed by the state server every time the title is authenticated and only the title object with the correct random value would be valid.
3.2.2 Networks, Network protocols, and Network Devices
A network is two or more computers or other devices connected together using a communication system for the purpose of communicating and sharing resources. A network session (or sometimes simply a session) includes a set of discrete network packets that effect a particular communication between one or more computers or devices.
Networks typically comprise dedicated hardware and software systems, commonly called network devices, which function in conjunction with communication links to operably connect two or more computers or network devices. Switches, routers, cable modems, wireless “access points”, and firewalls are all non-limiting examples of network devices. One particular type of network device is a wireless access point, such as produced commercially by Netgear of Santa Clara, Calif., Linksys of Irvine, Calif., and Skypilot Networks of Santa Clara, Calif. Wireless access points permit over the air (“wireless”) OSI level 1 and 2 communication links between computers and computer networks in accordance with one or more of the 802.11a, 802.11b, 802.11g, 802.11i, and other wireless protocols. Each wireless access point can be configured to respond to and be accessed using at least one public name called a service set identifier (SSID).
Network communications between computers, network devices, and other devices attached to a network are performed using one or more network protocols. The well-known Open System Interconnection (OSI) seven-layer networking model defines several types of network communication. These layers are generally considered a “link layer group” (OSI layer 1-2), “protocol layer group” (OSI layers 3-5), and “application layer group” (OSI layers 6-7). Network protocols may be categorized by the OSI layers in which they are supported, such as link layer protocols like 802.11 as described above, protocol layer group protocols such as TCP/IP, UDP, IPv4, IPv6, MPLS, DHCP, BOOTP, DNS, and application layer group protocols such as SMTP, POP, IMAP, HTTP, SOAP, and SMS. The computer-implemented software or firmware that implements some or all of a network protocol is commonly called a protocol stack.
Network devices typically facilitate movement of discrete units of information, called packets, over communication links between network devices and computers to effect communication and resource sharing. Sometimes, these networks are called packet-switched networks. Network devices inspect packets and process them according to information found in the packet's contents. Typically, this information is located in the packet header, although it could be located anywhere within a packet or sequence of packets.
A user, computer, or device can be granted access to some networks, computers, devices, or shared resources, and not to others, based on the level of service they have contracted for, company or government clearances, who they work for, and a variety of other factors. Access to one or more shared resources, and even to the network itself is provided on the basis of authentication and authorizations of a user, computer, or device. Authentication is the mechanism for proving an identity of the user, computer, or device. Authentication of users is often provided using a user id and password, a network address, or other information possessed by a user or known to the user. Often, these authentication methods rely on the user entering his authentication information into a computer which is then used to authenticate the user.
Authentication of computers and network devices is generally performed using automated mechanisms such as public key infrastructure (PKI). Additional sets of protocols are used to support authentication at a “protocol group layer” using variants of the EAP protocol, or an application group layer, such as RADIUS and Kerberos. Once identified, authorization materials associated with the user, computer, or device can be obtained and used to make access and provisioning decisions.
Authorization is a specification of what the user, computer, or device is allowed to do, and what resources the user, computer, or device is allowed to share and the subsequent enforcement of this specification to restrict or provide the resources authorized for a particular user, computer, or device. Authorizations may extend not only to the access to and use of one or more shared resources, but may include the manner in which one or more services or resources are provided and the percentage of network resources (such as bandwidth) that can be used by a particular user, computer, or device. A substantial infrastructure is required to provide for the authentication of users, computers, and devices, and to provide for the authorization and provisioning of the user, computer, or device in accordance with an authorization specification.
One challenge surrounding the use of network devices and systems is that they have differing authentication, authorization, and even expressions of rights. For example, a router from one network equipment provider may define user access and network traffic rights in a different way than a router from another provider, which in turn may define user access and networks rights differently than a DSL modem.
Additional challenges are provided when a plurality of network devices and servers require multiple authentications from a single user. As each of these authentications and authorizations typically require the user to enter information at a computer, a user is sometimes required to authenticate several times to gain access to a network resource. Additionally, there is generally not a mechanism by which a user can provide authentication or authorization materials to parts of the network between the user and an end network resource.
3.2.2.1 Internet Protocol Version 6 (IPv6)
IPv6 is a network layer protocol for packet-switched networking. It is intended as the successor of IPv4, which is the current version of the Internet Protocol in general use. The changes between IPv6 and IPv4 are relatively conservative, and most transport- and application-layer protocols need little or no change to work over IPv6.
The IPv6 proposed standard (RFC2460, Deering 1998) defines a basic header, and numerous extension headers, including an authentication header, a hop-by-hop options header, a routing header, or a destination options header that may be inserted into an IPv6 packet. FIG. 2 depicts an example of an IPv6 packet, where the IPv6 basic header 2100 is followed by any number of extension headers (2200a/b/c/ . . . ). 2200d depicts the detailed contents of an extension header.
When more than one extension header is used in the same packet, the recommended order is as follows:                IPv6 header (basic header)        Hop-by-hop options header—used to carry optional information that must be examined by every node along a packet's delivery path.        Destination options header (routing header associations)        Routing header—used by an IPv6 source to list one or more intermediate nodes to be “visited” on the way to a packet's destination.        Fragment header—used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination.        Authentication header—used to provide connectionless integrity and data origin authentication for IP datagrams, and to provide protection against replays.        Encapsulating security payload header—used to provide a mix of security services in IPv4 and IPv6.        Destination options header (options processed by final destination)—used to carry optional information that need be examined only by a packet's destination node(s).        Upper-layer header—a “pseudo header” for any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation. It uses 128-bit IPv6 addresses instead of 32-bit IPv4 addresses.        
IPv6 further defines destination (options) headers as implementation-specific headers. These headers provide space in the protocol frame into which applications or protocol stacks may insert implementation-specific materials, which are then used by applications present on routers, switches, servers, and other network devices to pass information within the protocol framework.
3.2.2.2 MPLS and Network Routing
In computer networking and telecommunications, MPLS is a network protocol that emulates some properties of a circuit-switched network over a packet-switched network. MPLS was designed to provide a unified data-carrying service for both circuit-based clients and packet switching network devices and network clients. It can be used to carry many different kinds of traffic, including IP packets, as well as native ATM, SONET, and Ethernet frames. The standards for MultiProtocol Label Switching (MPLS) are set forth in RFC3031, E. Rosen et. al., January 2001.
An IP packet comprises three elements: the first element is a header, which marks the beginning of the packet; the second element is the payload, which contains the information to be carried in the packet; and the third element is a trailer, which marks the end of the packet. Other protocols, such as XNS, have a similar structure. MPLS works by prepending protocol packets with an additional MPLS header, containing one or more “labels.” This list of labels in a MPLS header is commonly called a “label stack.” Prepending an existing protocol packet with a MPLS header transforms the existing packet into a MPLS payload. The standards for MPLS Label Stack Encoding are set forth in RFC 3032, E. Rosen et. al., January 2001.
In MPLS networking, a Label Switched Path (LSP) is a path through an MPLS network. An LSP is sometimes referred to as an “MPLS tunnel” because the forwarding of packets through an LSP is opaque to higher network layers. The LSP is set up based on criteria in the forwarding equivalence class (FEC), which is a group of IP packets that are forwarded in the same manner, over the same network path, and with the same forwarding treatment. FEC is typically determined by destination IP address, quality-of-service class, allocated bandwidth, and other implementation dependent factors.
The entrance and exit points of an LSP are both known as Label Edge Routers (LERs), sometimes called ingress and egress routers, or more generically, border routers. When an unlabeled packet enters the LSP path through the ingress router, the router first determines the FEC the packet should be in, appends a MPLS header to the packet, and then inserts one or more labels in the packet's newly created MPLS header. It then forwards the packet along to the next router in the path. Other routers along the path are known as Label Switching Routers (LSRs) or, more generically as transit routers.
When a labeled packet is received by a transit router, the topmost label is examined. Based on the contents of the label, a swap (swap to a new label), push (add another label to the stack), or pop (remove the top label from the stack) operation can be performed on the packet's label stack. Routers can have pre-built lookup tables that tell them which kind of operation to do based on the topmost label of the incoming packet. This enables the routers to process the packet very quickly.
During these operations, the contents of the packet below the MPLS label stack are not examined. The forwarding of the packet is done based on the contents of the labels, which allows “protocol independent packet forwarding” that does not need to look at a protocol-dependent routing table and avoids the computationally expensive IP longest prefix match at each hop along the path. At the egress router, when the last label has been popped, only the payload in the MPLS packet remains. This payload of the packet can be an IP packet, or any of a number of other kinds of information.
An aspect of MPLS routing is that routing must often be performed on the basis of an attribute of a user's device, such as the source IP address, the port that their network packets enter the ingress router on, or other networking-based attribute. There is no simple way to configure a user so that their traffic receives a specific quality of service or allocated bandwidth without considering aspects of the device that the user is using.
FIG. 3 illustrates an example of a conventional network configuration using MPLS routing. The example MPLS routed network comprises two individual networks (3100, 3200), such as those provided by Internet providers MCI or Sprint that are operably connected to interchange network traffic. Alternatively, the first network can be an enterprise network or metropolitan fiber network and the second network is the Internet or the network of a network service provider. Each network has one or more consumers, enterprises, or security islands operably connected to border routers (3115, 3125, 3135, 3145, 3155) as shown in the first network (3100). These border routers function as ingress and egress routers for network traffic flowing to and from the network. Each border router is connected to one or more additional routers, and is additionally connected to other routers within the network such as core routers (3110, 3120, 3130, 3140, and 3150) as shown in the first network (3100). A second network (3200) with a same or different topology may be connected at a border router that functions as a border router on more than one network (3125). Alternatively, the networks may be configured to pass network traffic from a first border router (3135) that is part of a first network to a second border router (3235) that is part of a second network. Each network manages network traffic within its boundaries in accordance with network traffic routing policies provided by each network's operator. In this example, network 3100 has a network traffic routing policy of routing network traffic that does not terminate within the network (e.g. network 3100) around the edge of the network (e.g. the EDGE policy). Network 3200 uses a different policy, in which all network traffic is routed through the core of the network (e.g. the CORE policy).
In one example, network traffic from a first user 3157 is routed to a first border router 3155 of network 3100, where it is inspected by the border router. The border router identifies the network address of the destination (3249) as belonging to network 3200, and has a routing policy that indicates that traffic should be routed in accordance with a specific routing policy that routes all traffic between the ingress and egress routers via edge routers (excluding the traffic from the core routers of the network). In this example, the routing policy is defined using a MPLS label corresponding to the “EDGE” policy that is configured as a LSP around the edge of network 3100 to the egress router (3125) that is operably connected to network 3200. The route of packets following the “EDGE” routing policy are depicted in FIG. 3 by traffic route 1 as indicated on the drawing by the line with dots and dashes. The first border router (3155), functioning as an ingress router, identifies the FEC corresponding to the traffic and adds a MPLS header and label corresponding to the “EDGE” routing policy to the network traffic. The router then routes the network traffic in accordance with its MPLS label, e.g. around the edge of the network to router 3115, then on to border router 3125. Border router 3125 functions as an egress router for network 3100 and as an ingress router for network 3200, and can operate in a variety of configurations. The net result of these configurations is typically that the network traffic is relabeled with a MPLS label corresponding to the “CORE” policy when it enters network 3200. The network traffic is then routed to its egress border router (for example, from 3220 to 3240 to 3245) and to its destination (3249). The route packets following the “CORE” routing policy are depicted in FIG. 3 by traffic route 2 (indicated with dashes).
Different routing policies may be applied based upon different source and destination addresses, network traffic type (e.g. VoIP traffic may have a higher priority than file transfer traffic), allocated bandwidth, desired quality of service, or other aspects of the network traffic. Unfortunately, there is no way for a user to connect in on various networks and receive an appropriate service level without a wide-reaching service infrastructure that encompasses all of the routers and requires specific authorization and sign-ons.
3.2.2.3 Provisioning, Dynamic Addressing and DHCP and BOOTP Protocols
Provisioning is the process by which a device is configured to operate on a network. In simplest form, a provisioning process is performed when a device is to be connected with a network. Provisioning may be manual, where a user or administrator forms the association between a device and a network, and optionally assigns one or more network configuration parameters such as network addresses to specific devices. Optionally, provisioning may be automatically performed. Numerous provisioning protocols have been introduced, one common protocol is called the Dynamic Host Configuration Protocol.
Dynamic Host Configuration Protocol (DHCP) is a network protocol for automatically provisioning devices on a network. DHCP is a client-server protocol between a “client” network device (e.g. the device that requires provisioning) and a “server” network device, which provides the provisioning information. DHCP is an extension to a prior generation provisioning protocol called BOOTP.
DHCP is generally used to assign network addresses and other network configuration parameters to devices that are connected to the network in a process called dynamic addressing. By using dynamic addressing, a device can have a different IP address and other network parameters each time it connects to the network. Many ISPs use dynamic IP addressing for dial-up users. In some systems, the device's IP address can even change while it is still connected. DHCP also supports a mix of static and dynamic IP addresses. The standards for Dynamic Host Configuration Protocol (DHCP) are set forth in RFC2131, R. Droms, March 1997. BOOTP is interoperable with DHCP, and is primarily described in RFC1534 and RFC1542.
Dynamic addressing simplifies network administration because the software keeps track of IP addresses rather than requiring an administrator to manage the task. This means that new devices can be added to a network without having to manually assign a unique IP address to each device. Dynamic addressing also allows network addresses to be assigned on an “as-needed” basis, which is increasingly important due to the finite number of IP addresses and the ever-increasing number of devices being used on networks (including computers, cellular phones, handheld devices, etc.).
FIG. 4 depicts the format used for DHCP messages. DHCP introduces a small change in terminology (from BOOTP) intended to clarify the meaning of one of the fields. What was the “vendor extensions” field in BOOTP has been re-named the “options” field (4130) in DHCP. Similarly, the tagged data items that were used inside the BOOTP “vendor extensions” field, which were formerly referred to as “vendor extensions,” are now termed simply “options.” Any DHCP packet may have options associated with it. In typical use, a client obtains network information, including IP address, from a DHCP server using the following process:
In a first step, sometimes called the “discovery” phase, the client broadcasts a DHCPDISCOVER message on its local network to find available DHCP servers. In some embodiments, a client may include “options” in its DHCPDISCOVER message. DHCP servers may use information in the DHCPDISCOVER message, including options information in determining whether to respond to a DHCPDISCOVER message.
In second step, known as the “offer” phase, the DHCP server responds to a client broadcast by reserving an IP address for the client and sending a DHCPOFFER message back across the network to the client. The DHCP server typically determines the IP address configuration based on its configuration database. In some embodiments, the determination is made based upon the client's hardware address (e.g. MAC) as specified in the CHADDR field (4120). The DHCP server specifies the reserved/offered IP address in the YIADDR (4110) field, and may provide other network configuration parameters options fields. The offered IP address and other network configuration materials are said to be “leased” to the network client/device.
In a third step, known as the “request” phase, the client receives the offer and requests the address that the server specified using a DHCPREQUEST message. If the client has received offers from multiple servers, it specifies the DHCP server from which it has accepted the offer and specifically rejects offers from all other servers. DHCPREQUEST also can be used to request the client's last-known IP address from a specific server. If the client is still in a network where the former IP address is valid, the server might grant the request. DHCPREQUEST also can be used to request an extension in the lease of an existing IP address.
In the fourth and final step, known as the “response” phase, the DHCP server receives the DHCPREQUEST message from the network client and returns a DHCPACK acknowledgment packet to the client. This packet includes information such as the lease duration for the IP address and any other network configuration information that the client might have requested. The client configures its network interface with the supplied information. At this point, the network configuration process is complete.
DHCP is implicitly limited in that it provides fixed network parameters, but is unable to request provisioning in accordance with rights or entitlements for other network-specific attributes such a quality of service or specific minimum or maximum bandwidth.
3.2.2.4 Wide Area and Public Network Access
FIG. 5 illustrates a conventional network where a user can be connected to the Internet (5300), to a private network (5400) (such as a corporate or campus network), to a partner network (5200) (such as AOL and Earthlink), or to a public network (5100) (such as wireless network “hot spots” provided by some cities, towns, and commercial providers such as Boingo Wireless of Santa Monica, Calif.). Networks often carry network traffic from a variety of customers; some of this traffic is accorded differentiated service levels based upon the user, their organization, or other criteria. In some cases, authentication to this class of network is by userid/password, pre-defined wireless access point credentials, or by other mechanisms. A user may have access to some network features and capabilities and not to others, based on the level of service they have contracted for, company or government clearances, and a number of other factors. Furthermore, an individual user may be entitled to one or more levels of service upon the basis of a plurality of memberships or other rights that they have based upon group or organization membership, subscription, or other attribute.
Today, each individual differentiation mechanisms requires the user to have separately pre-programmed their personal devices. This is costly from a provisioning and support standpoint. Additionally, the network provider must provide specialty provisioning at nodes and points of presence of wide area and public networks in order to support a plurality of types of differentiated service. Again, this is costly from a provisioning and deployment standpoint. Depending upon the equipment used in constructing the network, there are various limitations in the number of types of specialty provisioning that are supported for each point of presence. These costs and limitations limit the number and types of traffic that may connect to a point of presence and be served by a wide area or public access network.
An example of a typical public wireless network (5500) is shown in FIG. 5, such a public network might be found within airports, malls, coffee shops, and other locations. Alternatively, such a public network might be a simplified network diagram of a citywide wireless network of the type being installed in major metropolitan areas around the USA. Such a typical public wireless network might include a plurality of wireless access points (5510a/b/c), using such technologies as 802.11a, 802.11b/g, mesh networking technologies, and other wireless networking mechanisms known to those skilled in the art. Collectively, these are the points of presence for the wireless network. Each of these points of presence is connected using traditional networking technologies to one or more wireless gateways, routers, or switches. The wireless gateway is used to route DHCP and subsequent authentication traffic to one or more DHCP servers (5522) and RADIUS servers (5524) operable on the public wireless network. In some embodiments, the DHCP server and RADIUS server chosen may be one of a network connected to an example of a public wireless network. The DHCP server may provide different network configuration parameters (e.g. network and gateway addresses) to a device connecting to the wireless network based upon, for example, the SSID of a wireless access point that the device is connected to. Setting up each of these SSIDs and managing the DHCP services based on the SSID is a complex and time consuming task, and is further complicated by authentication requirements once the connection is established. The use of static SSIDs requires the use of real-time authentication mechanisms, as a device that is no longer eligible to access the network may retain the SSID configuration on their wireless device after their privileges have lapsed.
In some implementations, separate authentication mechanisms must be provided by a network provider to require that users of devices connected to a network are actually authorized to use the network. Failure to separately authenticate to the network may cause a device or user of a device to not receive contracted levels of service from the network, if service is provided at all.
Network traffic to and from the wireless access points (5510a/b/c) and the Internet (5300) and private (5400) or public (5100) networks attached to an example of a public wireless network (5500). In some network implementations, the network traffic is routed using MPLS or a related routing technology. Any required differentiated service that is performed or managed can also be provided using MPLS or a related routing technology, as described above.
One additional aspect of conventional wireless networks is that a user must often be able to operate on one or more of these networks because they “roam” from network to network. This increases the complexity of the network, requires a plurality of RADIUS and other authorization/authentication servers, and complicates the user's portable device configurations. Each configuration of the user's portable device also may interfere with one or more other configurations of the portable device.